# Performance Optimization Tips

***Copyright © Quectel Wireless Solutions Co., Ltd. 2026. All rights reserved.***

---

# Available Performance Tools

| **Tool** | **Purpose** | **Example Command** |
| --- | --- | --- |
| `top` | View real-time process, CPU, and memory usage. | `top -b -n 1` |
| `ps` | View processes sorted by CPU or memory usage. | `ps -eo pid,ppid,comm,%cpu,%mem,args --sort=-%cpu` |
| `uptime` | View uptime and system load. | `uptime` |
| `mpstat` | View overall CPU utilization. | `mpstat 1 2` |
| `vmstat` | View rough CPU, memory, swap, and I/O status. | `vmstat 1 2` |
| `free` | View memory and swap usage. | `free -h` |
| `iostat` | View block device I/O statistics. | `iostat -d -k 1 2` |
| `df` | View filesystem space usage. | `df -h` |
| `du` | View directory space usage. | `du -sh /data/*` |
| `lscpu` | View CPU architecture and frequency information. | `lscpu` |
| `lsblk` | View block devices and mount relationships. | `lsblk` |
| `sysctl` | View kernel parameters. | `sysctl vm.swappiness` |
| `systemctl` | View service status. | `systemctl --failed --no-pager` |
| `journalctl` | View service or system logs. | `journalctl -p err -n 50 --no-pager` |
| `ping` | Basic network connectivity test. | `ping -c 3 127.0.0.1` |

# System Performance Monitoring

## View Overall Load

Use `uptime` first to view system uptime and load average:

```bash
adb shell 'uptime'
```

The sample output contains `load average`. If the load average remains significantly higher than the CPU core count for a long time, further check CPU, I/O, or process usage.

## View Process CPU and Memory Usage

Use `top` to view current system processes, CPU, and memory overview:

```bash
adb shell 'top -b -n 1 | head -20'
```

To quickly locate processes with high CPU usage, use:

```bash
adb shell 'ps -eo pid,ppid,comm,%cpu,%mem,args --sort=-%cpu | head -12'
```

To sort by memory usage, use:

```bash
adb shell 'ps -eo pid,ppid,comm,%cpu,%mem,args --sort=-%mem | head -12'
```

## View CPU Utilization

`mpstat` can observe the proportions of user mode, kernel mode, I/O wait, and idle CPU time:

```bash
adb shell 'mpstat 1 2'
```

In this test, `mpstat` ran normally. The average idle ratio in the example was about 92% or higher, indicating that overall CPU pressure was not high during the test.

## View CPU Frequency and Scheduling Policy

CPU0-7 are currently online on the development board. View them with:

```bash
adb shell 'cat /sys/devices/system/cpu/online'
```

View the current CPU governor:

```bash
adb shell 'for f in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do [ -e "$f" ] && printf "%s=" "$f" && cat "$f"; done'
```

The governors of CPU0-7 are all `performance`. Available governors include `userspace`, `ondemand`, `walt`, `conservative`, `powersave`, `performance`, and `schedutil`.

View the current frequency:

```bash
adb shell 'for f in /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq; do [ -e "$f" ] && printf "%s=" "$f" && cat "$f"; done'
```

In this test, CPU0-3 were about 1804800 kHz, and CPU4-7 were about 2016000 kHz.

# Memory and Swap Monitoring

## View Memory Usage

Use `free` to view memory, cache, and swap usage:

```bash
adb shell 'free -h'
```

In this test, total system memory was about 3.5 GiB, available memory was about 2.4 GiB, and swap was about 1.8 GiB with no obvious usage.

## View vmstat

`vmstat` can quickly observe run queue, memory, swap, I/O, and CPU usage:

```bash
adb shell 'vmstat 1 2'
```

Focus on:

- `r`: run queue. If it remains high, the CPU may be busy.

- `si` / `so`: swap in/out. Continuous non-zero values indicate high memory pressure.

- `wa`: I/O wait. Continuous high values indicate that storage I/O may be a bottleneck.

- `id`: CPU idle. Continuous low values indicate high CPU utilization.

## View zram swap

The current system uses `/dev/zram0` as swap. View it with:

```bash
adb shell 'cat /proc/swaps; zramctl 2>/dev/null || true'
```

In this test, `/dev/zram0` was about 1.8 GiB, priority was 32758, and it was almost unused.

# Storage I/O and Space Check

## View Filesystem Space

Use `df` to view space usage of each mount point:

```bash
adb shell 'df -h'
```

In this test, the root filesystem `/` was about 7.8 GiB with about 4.1 GiB used; `/data` was about 40 GiB with sufficient remaining space. Large logs, test files, and temporary data should preferably be placed under `/data` or `/tmp` to avoid filling the root filesystem.

## View Directory Usage

To locate large files or directories, use:

```bash
adb shell 'du -sh /data/* 2>/dev/null | sort -h | tail -20'
```

If checking root filesystem space, change the target to directories such as `/var`, `/usr`, and `/opt`.

## View Block Devices

Use `lsblk` to view block devices, partitions, and mount points:

```bash
adb shell 'lsblk'
```

The main storage device is currently `mmcblk0`; system, cache, and data partitions are mounted from different partitions of this block device.

## View I/O Statistics

The `iostat` on the current development board is the BusyBox version and does not support the `-x` extended option. Use the following command to view basic block device I/O:

```bash
adb shell 'iostat -d -k 1 2'
```

To observe CPU and I/O status together, combine it with `vmstat 1 2`.

# Network Status Check

The current development board can use `ip` and `ping` for basic network checks:

```bash
adb shell 'ip -br addr; ip route'
```

In this test, `wlan0` and `p2p0` were `DOWN`, and no default route was found. Therefore, external network throughput or bandwidth test procedures are not suitable for this document at present.

Local loopback connectivity can be verified with:

```bash
adb shell 'ping -c 3 -W 1 127.0.0.1'
```

In this test, the loopback ping test had 0% packet loss, which can be used to confirm that the basic network stack works normally.

# Service and Log Troubleshooting

## View Failed Services

Service exceptions may affect boot speed, background resource usage, and functional stability. First view failed services:

```bash
adb shell 'systemctl --failed --no-pager'
```

In this test, several failed services existed, such as `camera_cgroup.service`, `lefbe.service`, `pulseaudio.service`, `qwesd.service`, and `thermal-engine.service`. Whether they need to be optimized or disabled should be judged according to the corresponding functional requirements.

## View Error Logs

View recent error logs:

```bash
adb shell 'journalctl -p err -n 50 --no-pager'
```

To view logs of a specific service, use:

```bash
adb shell 'journalctl -u SERVICE_NAME --no-pager -n 100'
```

When troubleshooting service-related performance problems, first confirm whether services are repeatedly restarting, blocking startup, or continuously printing error logs.

# View Kernel Parameters

The current system can use `sysctl` to view some kernel parameters:

```bash
adb shell 'sysctl kernel.kptr_restrict kernel.perf_event_paranoid vm.swappiness vm.dirty_ratio vm.dirty_background_ratio net.core.rmem_max net.core.wmem_max'
```

Measured values in this test include:

- `kernel.kptr_restrict = 2`

- `kernel.perf_event_paranoid = 2`

- `vm.swappiness = 100`

- `vm.dirty_ratio = 20`

- `vm.dirty_background_ratio = 10`

- `net.core.rmem_max = 1048576`

- `net.core.wmem_max = 1048576`

Changing kernel parameters affects system behavior. Before making formal changes, evaluate the specific issue and keep the original values for rollback.

# Process Priority and CPU Affinity

The current system can use `nice`, `renice`, `ionice`, and `taskset`. These tools are suitable for temporarily adjusting process priority or CPU affinity during debugging.

## Check Whether Commands Exist

```bash
adb shell 'command -v taskset; command -v nice; command -v renice; command -v ionice'
```

## Example: Run a Command on Specified CPUs

```bash
adb shell 'taskset -c 0-3 COMMAND'
```

## Example: Adjust Process Priority

```bash
adb shell 'renice -n 5 -p PROCESS_PID'
```

These commands change process scheduling behavior. Use them only when the target process and test purpose are clear.

# Temperature Status View

Thermal sysfs can be used to view temperatures of each thermal zone:

```bash
adb shell 'for z in /sys/class/thermal/thermal_zone*; do [ -e "$z/type" ] && printf "%s " "$(cat "$z/type")" && cat "$z/temp" 2>/dev/null; done | head -40'
```

In this test, thermal zones such as `cpu-1-0`, `cpu-1-1`, `cpu-1-2`, `gpu`, `wlan`, and `video` could be read. Temperature values are usually shown in millidegrees Celsius; for example, `50800` means about 50.8°C.

# Optimization Troubleshooting Flow

1. Run `uptime` and `top -b -n 1` first to determine whether the system is generally busy.

2. If CPU usage is high, use `ps --sort=-%cpu` and `mpstat` to locate the process and CPU utilization.

3. If memory is tight, use `free -h`, `vmstat 1 2`, and `cat /proc/swaps` to view available memory, swap, and zram status.

4. If the system is sluggish but CPU usage is not high, use `vmstat` and `iostat -d -k 1 2` to check for I/O wait or storage access pressure.

5. If boot is slow or background services are abnormal, use `systemctl --failed` and `journalctl -p err` to view failed services and error logs.

6. If overheating or frequency throttling is suspected, check `scaling_cur_freq`, `scaling_governor`, and thermal zone temperatures.

7. If a network issue is involved, confirm `ip -br addr` and `ip route` first, then run connectivity tests.

# Notes

- This document only keeps tools and commands verified as available on the current development board.

- Tools such as `perf`, `htop`, `sar`, `pidstat`, `stress-ng`, and `sysbench` are not included in the current workflow.

- The current `iperf3` command has a missing dependency library issue, so it is not included in this network throughput test workflow.

- When operating governor, sysctl, renice, ionice, or service start/stop settings, clarify the test purpose first and record the state before modification.

- For formal optimization, change only one variable at a time and record `top`, `vmstat`, `mpstat`, `iostat`, `journalctl`, and other results before and after the change, to avoid being unable to determine which change produced the effect.

# Summary

The current development board can use basic Linux tools to troubleshoot CPU, memory, storage, services, logs, temperature, and basic network status. During performance optimization, first use read-only commands to identify the bottleneck source, then narrow down the issue by CPU, memory, I/O, services, logs, and temperature. Tools that are currently unavailable or have incomplete dependencies should not be added directly to regular operating procedures.